Certainly a workaround hack, so please ensure to properly mark down that this needs changing in the future.

I think you mentioned a process that was something along the lines of duplicating the existing positions and making "defeat" versions with their own dialog. I haven't actually looked into the code to find where I'd have to make changes to do that yet but it seemed too complicated for my fried brain so I just added this for now.

On the main node objects themselves, the available positions are defined.

"sexboundConfig" : {
    "animationPartsCentered": false,
    "position" : {
      "sex" : [ "standing", "doggy", "missionary", "cowgirl", "facesitting", "butterfly", "fellatio", "reverse_cowgirl" ]
    }
  }

You'd change these to different one. I'd just rename them all to "*_defeat". These new positions also need to be defined in /positions/positions.config. That file maps the name to the actual file path. Then just add the new positions.

In the new position configs, you would mostly just define "base" : "<base position name>" to have ALL of the base position's data, then just overwrite the "dialog": {} table to link to new defeat specific dialog files for each race.

That's pretty straightforward. I'll add in that functionality. Writing the actual dialog however isn't as much in my wheelhouse so I'd leave those free to be filled in if that's alright.

It appears you are missing the part where you actually set self._containsDefeated, which is used a couple lines further down.

This gets set later lines 380-382. The checks on 358 and 372 are for when an actor joins a node that already contains a defeated actor.

So, you are doing it this way to lock the node up once a second actor joins, assuming the defeated one is the first?

You also mentioned in the potential issues that this potentially disallows 3 actors and causes PVP problems with the defeated player interacting with their own node in time. There is a better solution to this problem. I don't know if there is a way to, via status effect, turn of a players ability to interact as a whole, but even if not you'd just need to edit the "onInteraction" function on the main node itself. The node upon creation gets the entity ID of the OG "defeated" target and, in the "onInteraction" function, if the interacting entity is that ID just null their lounge request. The "onInteraction" method is supposed to return nil or the name of an interaction type - the entity only lounges if the response is nil (and it's a loungable) or specifically the lounge operation. You can look up in the StarGlue repo what the allowed types are, or I can check it in a bit, cause I have done something similar for the Neki race mode whereas non-Nekis cannot lounge in a specific object.

EDIT: Looked up the nulling of the lounge request. It's:
return {"Message", {messageType = "noop", messageArgs = {}}}
(Where "noop" is just the name of ANY type of entity Message that has NO handler attached to it, otherwise it would call the message handler.)

I did look into nullifying specific lounge requests using "onInteraction" but had no luck with my attempts. I think I had it returning nil expecting it to just skip the lounge handling but that makes sense. Am I right that what you're saying is that I could just have it do the entity ID check and have it return that exact message that you wrote?

Yep. You just need to somehow transmit the source entity's ID on transformation, so the node inherently knows...
...actually, no you don't. You just block requests of the entity IDs of every actor that is already in there. The data is all there once the "lounging" is successful. Though that would still leave room for accidents with conveniently interacting the tick the node is spawned, so maybe still transmit the source entity's ID in the transformation itself, and lock that one out.

Returning the above will nullify the lounge request, because the interaction actually tries to trigger a message handler that should not exist, and hence does nothing.

Seems clear to me! I'll work on that change.

Should potentially be made a config option, to be changed alongside how long the node stays.

That's a good idea, I'll look into implementing that.

I have removed the starve protection from all sexnodes so far, so for consistency this needs to go aswell.

HOWEVER, this brought up another question. What happens if you die inside of a sexnode? E.g. starve to death mid sex. How does defeat handle this?

You can still take damage while in sexnodes, since being defeated is the only thing that prevents damage at the moment. If you die, something weird happens and not only are you killed, but then you also die. Which is a funny way to say you die twice.

Anyway I can remove that.